Systems, Methods, and Computer Program Products for Providing Data Use Options

ABSTRACT

Systems, methods, and computer program products are provided for location-based distribution of data. One or more sets of data from one of a plurality of partner systems are received and stored, each set of data including at least one of a location data and a range. Application information associated with each application of a plurality of applications stored on respective mobile device is retrieved. The application information includes at least application location information. A pool of eligible applications are identified from the plurality of applications, based on the application location information of each of the plurality of applications and at least one of the location data and range of one of the one or more sets of data. A message is generated for each of the applications in the pool of eligible applications, the message including at least a portion of the one of the one or more sets of data. The respective messages are transmitted over a communications network to the applications in the pool of eligible applications.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Application No.61/935,023, filed Feb. 3, 2014, the contents of which are incorporatedherein by reference.

BACKGROUND Field

The present invention relates to distribution of data, and moreparticularly to systems, methods, and computer program products forproviding location-based distribution of data.

Related Art

Merchants often operate under very low margins. As such, the objectiveof any merchant is to get inventory available for sale, sold, andrestocked as quickly as possible.

To that end, management of inventory and supply chain (the system oforganizations, people, activities, information, and resources involvedin moving a product or service from supplier to sale) is vital tosuccess. For example, it is important to move inventory to locationswhich are lacking in such inventory, so that the inventory can bestocked and sold. Otherwise, the merchant misses out on a sale (or,often, multiple sales). Inventory may also be moved for otherconsiderations. For example, a merchant may want to move inventory outof a location with excess inventory by increasing sales at thatlocation, rather than paying overhead costs involved in moving theinventory to other locations.

In that regard, the increase in mobile devices allows for increasedflexibility for inventory management. For example, since a mobile devicemay move in and out of different locations, there is a need to alert themobile device of sales in a particular location or locations, based onwhere the inventory is or needs to be sold. On the other hand, sincesales are often completed online with a mobile device without visiting astore, there is also a need to facilitate online sales while accountingfor location-based inventory concerns (e.g., offering online sales onlyto devices near locations where excess inventory exists and/or can beshipped from cheaply).

Thus, one technical challenge involves providing data such as offersfrom merchant systems to mobile devices and/or applications based on thelocation of the mobile device and/or application.

BRIEF DESCRIPTION

The example embodiments presented herein address the above-identifiedneeds by providing systems, methods, and computer program products forproviding location-based distribution of data.

In one embodiment, a system is provided for location-based distributionof data. The system includes at least one memory operable to store oneor more sets of data received from one of a plurality of partnersystems, each set of data including at least one of a location data anda range, and a processor coupled to the memory. The processor isoperable to retrieve application information associated with eachapplication of a plurality of applications stored on respective mobiledevices, the application information including at least applicationlocation information. The processor is further operable to identify apool of eligible applications from the plurality of applications, basedon the application location information of each of the plurality ofapplications and at least one of the location data and range of one ofthe one or more sets of data. The processor is also operable to generatea message for each of the applications in the pool of eligibleapplications, the message including at least a portion of the one of theone or more sets of data, and to transmit the respective message, over acommunications network, to the applications in the pool of eligibleapplications.

In another embodiment, a method is provided for location-baseddistribution of data. One or more sets of data from one of a pluralityof partner systems are received and stored, each set of data includingat least one of a location data and a range. Application informationassociated with each application of a plurality of applications storedon respective mobile device is retrieved. The application informationincludes at least application location information. A pool of eligibleapplications are identified from the plurality of applications, based onthe application location information of each of the plurality ofapplications and at least one of the location data and range of one ofthe one or more sets of data. A message is generated for each of theapplications in the pool of eligible applications, the message includingat least a portion of the one of the one or more sets of data. Therespective messages are transmitted over a communications network to theapplications in the pool of eligible applications.

In yet another embodiment, a non-transitory computer readable storagemedium is provided having stored thereon instructions which, whenexecuted by a system including at least one processor and at least onememory, cause the system to receive and store one or more sets of datafrom one of a plurality of partner systems, each set of data includingat least one of a location data and a range. The instructions furthercause the system to retrieve application information associated witheach application of a plurality of applications stored on respectivemobile devices, the application information including at leastapplication location information, and cause the system to identify apool of eligible applications from the plurality of applications, basedon the application location information of each of the plurality ofapplications and at least one of the location data and range of one ofthe one or more sets of data. The instructions additionally cause thesystem to generate a message for each of the applications in the pool ofeligible applications, the message including at least a portion of theone of the one or more sets of data. The instructions also cause thesystem to transmit the respective message over a communications networkto the applications in the pool of eligible applications.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will become moreapparent from the detailed description set forth below when taken inconjunction with the following drawings.

FIG. 1 is a diagram of a mobile commerce system for providinglocation-based distribution of data according to an exemplaryembodiment.

FIG. 2 is another diagram of the mobile commerce system for providinglocation-based distribution of data according to an exemplaryembodiment.

FIG. 3 is a flowchart illustrating the steps for providinglocation-based distribution of data according to an exemplaryembodiment.

FIG. 4 is a view for illustrating location-based distributed datadisplayed on a mobile device according to an exemplary embodiment.

FIG. 5 is a block diagram of a general or special purpose computer.

DETAILED DESCRIPTION Overview

The example embodiments presented herein are directed to systems,methods, and computer program products for location-based distributionof data, which are described herein in terms of an example mobilecommerce environment.

According to embodiments described herein, one or more sets of data(e.g., offers) including location data and a range are matched tolocation information of a plurality of applications stored on respectivemobile devices, and the sets of data are transmitted to the applicationsover a network.

The features discussed above are described in further detail below, withreference to FIGS. 1-5 .

It should be understood that while the invention is described below inthe context of providing offers from merchants to mobile applications onmobile devices, any type of data may be distributed among any types ofsystems and/or devices, based on the location of one or more of thesystems and/or devices.

The terms “wallet client”, “mobile wallet application”, or “mobilewallet” and/or the plural forms of these terms are used interchangeablyherein to refer to a mobile wallet application deployed, stored and/orfunctioning on a mobile device.

System

FIG. 1 is a diagram of a system 100 for providing location-baseddistribution of data according to an exemplary embodiment. As shown inFIG. 1 , system 100 includes mobile devices 120-1, 120-2, . . . , 120-n(collectively “120” or “mobile devices 120”); a mobile commerce (MoCom)platform 130 including a wallet server system 170; merchant systems140-1, 140-2, . . . , 140-n (collectively “140” or “merchant systems140”); and communication network 150.

Mobile devices 120 may be, for example, a cellular phone, tablet or thelike. Each of mobile devices 120-1, 120-2, . . . , 120-n includes aprocessor, memory, and an output display such as a display screen, asdescribed in more detail below with reference to FIG. 2 . A secureelement (SE) may be included in each mobile device, and may beimplemented as a Universal Integrated Circuit Card (UICC), embedded SEcard, secure micro secure digital (microSD) card, and the like. A secureelement may also be implemented outside of the mobile device with whichit is associated. For example, a secure element may be implemented in acloud-based, remote or virtual storage, and the like.

Mobile devices 120-1, 120-2, . . . , 120-n include or have storedthereon a wallet client application 125-1, 125-2, . . . , 125-n(collectively “125” or “wallet client applications 125”), which includeinstructions that when executed by the processor of the correspondingmobile device 120, cause the mobile device to act as an instrument, forexample, for processing contactless transactions.

Offers used during a transaction may be stored and managed by the MoComplatform 130. In one example embodiment, the MoCom platform 130 mayinclude wallet server system 170. Wallet server system 170 is hardwareand/or software for storing data associated with, for example, mobiledevices 140, mobile network operators (MNOs), wallet client applications125, secure elements, and the like. In one example embodiment, walletserver system 170 stores mobile wallet application profiles (e.g., forwallet client application 125-1), which may include mobile device, user,mobile wallet application and transaction data. Wallet server system 170may also include one or more databases, such as an offer database forstoring offers or offer data, and may be configured to manage (e.g.,transmit, receive, request, process) offers and their related data. Forexample, wallet server system 170 may store and manage mobile commercedata (e.g., offer data, loyalty data, rewards data), merchant data(e.g., information related to merchants associated with commerce data),and rules and/or means for processing redeemed offers, distributingoffers to wallet client applications, and the like, as described belowin further detail with reference to FIG. 2 .

MoCom platform 130 may be a standalone platform, or may be part of amobile wallet system and/or architecture. The mobile wallet systemand/or architecture may include various systems such as a trustedservice manager (TSM) and/or an enterprise service bus (ESB). The ESBand TSM are systems that provide interfaces and/or communications meansbetween multiple systems internal or external to the mobile walletsystem and/or architecture, such as providing additional interfaces tofacilitate payment and commerce transactions using wallet clientapplications 125.

MoCom platform 130 is communicatively coupled to merchant systems 140over a communications network 150. A merchant system such as merchantsystem 140-1 is a system, platform, computer architecture or the like,managed by a partner and/or merchant (e.g., business, retailer). Themerchant system may include a customer relationship marketing (CRM)system or logic, which is used to analyze, manage and distribute offers.In one exemplary embodiment, a merchant system creates an offer andtransmits that offer to the MoCom platform 130 to be certified,configured, stored and/or distributed to wallet client applications 125on mobile devices 120. The creation and management of offers isdescribed in further detail in U.S. Patent Application Publication Nos.US 2014/0032312 and US 2014/0074616, which are incorporated herein byreference in their entirety.

FIG. 2 is a more detailed view of a merchant system (e.g., merchantsystem 140-1), a wallet server system (e.g., wallet server system 170)and a wallet client application (e.g., wallet client application 125-1)on a mobile device (e.g. mobile device 120-1) shown in FIG. 1 . Theseelements and/or systems provide location-based distribution of data overcommunication network 150 according to an exemplary embodiment.

In particular, FIG. 2 illustrates networking tools used to enabledistribution of merchant offers to wallet client applications 125 (ormobile devices 120). Although merchant system 140-1, wallet serversystem 170 and mobile device 120-1 are shown as single componentscommunicating directly, it should be understood they may be part of asystem of many such components which may be centrally located ordispersed geographically and connected through disparate networkingsystems, e.g., cloud computing services. In addition, each of theelements in FIG. 2 may be implemented by hardware, software, or somecombination of the two.

Merchant system 140-1 includes the tools necessary to transfer offercontent to a wallet server system 170, to in turn deploy the offercontent to a wallet client application or applications (e.g., the walletclient application 125-1 on mobile device 120-1) which correspond to anoffer campaign. For example, merchant system 140-1 may define an offercampaign in which offers are deployed only to mobile devices within arange of certain locations, as a means of moving inventory in and/or tothose locations.

Merchant system 140-1 may include, for example, processor 201, which maybe a central processing unit (CPU) or multiple CPUs, as hardware thatcarries out the instructions of a computer program by performing thearithmetical, logical, control and input/output operations of thesystem.

Merchant system 140-1 may further include memory operating system (OS)and kernel 202. The operating system is hardware and/or software whichperforms tasks such as recognizing input from input devices, sendingoutput to other devices such as a display screen, keeping track of filesand directories on a disk, and controlling peripheral devices such asdisk drives and printers. The kernel is the central module of the OS.The kernel is generally the part of the operating system that loadsfirst, and it remains in main memory. The kernel is responsible formemory management, process and task management, and disk management, andconnects the system hardware to application software.

Additionally, merchant system 140-1 may include file system 203 ashardware and/or software for managing files in the system, andspecifically for controlling how data is stored and retrieved. Filesystem 203 may allocate space in a granular manner, and may use multiplephysical units on the device. File system 203 is responsible fororganizing files and directories, and keeping track of which areas ofthe media belong to which file and which are not being used.

Merchant system 140-1 may further include notifyd 204, which is hardwareand/or software including a daemon (e.g., background process) forpassing event notifications between processes and/or to the user. Forexample, notifyd 204 may generate small, passive popup dialogs thatnotify the user of particular events in an asynchronous manner.

Merchant system 140-1 may also include imapd 205, which is hardwareand/or software for communicating via the Internet Message AccessProtocol (IMAP). Generally, imapd runs automatically after receiving anetwork connection, accompanied by the appropriate userid and password,and manages incoming and outgoing mail in the IMAP format.

Additionally, merchant system 140-1 may include user agent 206, which ishardware and/or software for acting on behalf of a user. For example,user agent 206 may operate in a network protocol by identifying itselfand its user, its application type, operating system, software vendor,or software revision, by submitting a characteristic identificationstring to its operating peer. In the context of merchant system 140-1,therefore, user agent 206 might act on behalf of the merchant usercurrently logged into the system, e.g., a manager at a store location.

Merchant system 140-1 may include database 207, which is hardware and/orsoftware for storing an organized collection of data, typicallyorganized to model aspects of reality in a way that supports processesrequiring information. For example, database 207 may store datacorresponding to offer content, prior to transmission to wallet serversystem 170.

Merchant system 140-1 may also include httpd/ftpd/smsd 208, which ishardware and/or software including a respective daemon (backgroundprocess) for communicating via each of the Hypertext Transfer Protocol(http), File Transfer Protocol (ftp), or Short Message Service (sms)protocol. For example, httpd/ftpd/smsd 208 may create a pool of childprocesses or threads to handle http requests.

Merchant system 140-1 may further include network interface 209, whichis a hardware and/or software interface between merchant system 140-1and a network such as communication network 150. Thus, for example,network interface 209 may provide standardized functions such as passingmessages, connecting and disconnecting, and the like.

Additionally, merchant system 140-1 may include smtpd 210, which ishardware and/or software including a daemon for communicating via SimpleMail Transfer Protocol (smtp). For example, smtpd 210 may listen forincoming mail and place it in a private queue.

Merchant system 140-1 may also include hard drive 211. Hard drive 211 ishardware and associated software acting as a data storage device forstoring and retrieving digital information. Hard drive 211 retains itsdata even when powered off. While hard drive 211 is explained in thecontext of a hard disk, it should be understood that other persistentmemory may be used, such as solid-state drives (SSDs).

As can be seen in FIG. 2 , merchant system 140-1 transmits an offercontent message including offer content to wallet server system 170.

Wallet server system 170 stores offer content received from merchantsystem 140-1. In that regard, the general structure and function ofprocessor 271, memory OS and kernel 272, file system 273, imapd 275,httpd/ftpd/smsd 278, network interface 279 and smtpd 280 corresponds tothe same elements described above with respect to merchant system 140-1,and as such for purposes of conciseness will not be repeated. Of course,it should be understood that the specific functions of these elementsmay be tailored to the functionality of wallet server system 170.

Wallet server system 170 further includes geo-location services 274,which is hardware and/or software which may store merchant definedlocation and range data defined by an offer for mobile devices 120 astargets of the offer, as shown below in Table 1. Geo-location services274 may also include hardware and/or software for receiving and storingthe location of mobile devices 120 (e.g., mobile device 120-1) and/orwallet client applications 125 (e.g., wallet client application 125-1)from location services 223 in mobile device 120-1. In that regard,mobile device 120-1 may ascertain its location with location servicesinterface 223 as by using, e.g., Global Positioning System (GPS)coordinates or radio frequency (RF) location methods, and mayperiodically transmit such information to wallet server system 170.Alternatively, wallet server system 170 may periodically request suchinformation from mobile device 120-1, e.g., when a new offer is receivedfrom merchant system 140-1.

Wallet server system 170 also includes a database 277 for storing offercontent received from merchant systems such as merchant system 140-1,and wallet client application information identifying wallet clientapplication 125-1. An example of offer content that might be stored indatabase 277 is depicted below in Table 1 (“Merchant Offer ContentTable”). Database 277 may also store wallet client applicationinformation about a wallet client application (e.g., wallet clientapplication 125-1) on a mobile device (e.g., mobile device 120-1), andmay include associated wallet client application location data, such asthat depicted below in Table 2 (“Wallet Client Application LocationTable”). It should be understood that these tables are merely examples,and the type, volume, arrangement and identity of the stored informationmay vary.

TABLE 1 Merchant Offer Content Table (Online & Store Specific) MerchantDefined Internal Merchant Location Data and Local Specific ID Offer IDAssociated Range Offer Content Store Data Use Case 99 16833456 ZipCodes: 75202, Ace Laptop {32.862845, −96.754540} Online 75203, 75206,Computer {32.862845, −96.754540} Only- 75208, etc . . . $199.00 LimitedLatitude/Longitude: Valid Through Physical {32.56.2960, Sep. 24, 2014Use 96.49.1062} Locations Latitude/Longitude Range: {34.36.4718,96.49.1000; 32.55.3468, 94.50.1749; 31.16.0814, 96.49.1000; 32.55.3486,98.47.9076} 300 56892233 National Back to School {32.862845, −96.754540}Online Special Two {32.862845, −96.754540} Only- General Purpose{32.862845, −96.754540} Limited Backpacks {32.862845, −96.754540}Physical $15.99 Use Valid Through Locations Oct. 10, 2014 350 88963443ARegional: TX, OK, Main L-Shaped {32.862845, −96.754540} Online LA, MISS,ARK Desk and Only- Hutch 124.00 Limited Physical Use Locations

TABLE 2 Wallet Client Application Location Table Internal ID Internal IDLocation Data (from Table 1) 88 Latitude/Longitude: 99 {32.56.2960,96.49.1062} Zip Code: 75202 764 Latitude/Longitude: 300 {33.6790,−117.905635} Zip Code: 92626 1234 Latitude/Longitude: 350 {32.862845,96.754540} Zip Code: 75201

As shown in Table 1, the merchant offer content might include aninternal identification (ID), which is a number, letter, characterstring, or the like which identifies the offer within the wallet serversystem 170. The internal ID may be, for example, assigned upon receptionof the corresponding offer.

A Merchant Offer ID may identify the offer at merchant system 140-1, ormay identify the offer globally throughout the environment shown in FIG.1 .

Merchant Defined Location Data and Associated Range includes thegeographic location and range where the offer is valid/to betransmitted. In that regard, the location and range can be defined invarious ways. For example, as shown in Table 1, the location may bedefined as a GPS coordinate, with the range being defined as a set ofGPS coordinates surrounding or near the location coordinate. In anotherexample, both the location and range may be defined using one or morezip codes, since zip codes have a predetermined range. The location andrange could also be defined, as shown, by one or more states, countries(e.g. nationally), or other divisions.

Table 1 further includes Offer Content, which defines the actual boundsof the offer, and which may include the text transmitted to mobiledevices 120 or wallet client application 125 in a matching location.Thus, for example, offer content might include “Ace Laptop Computer−$199.00—Valid Through 09/24/14”.

Local Specific Store Data may comprise a location or range from whichthe inventory may be shipped, e.g., in the case that a user of mobiledevice 120-1 or wallet client application 125-1 decides to accept theoffer and purchase the product. As mentioned above, defining thelocations from which purchased inventory can be shipped allows themerchant better control of inventory and supply chain logistics, forexample by reducing excess inventory at certain locations.

Table 1 further includes a Use Case, which may be used to defineadditional conditions of the offer or how the offer may be used. Forexample, the Use Case may define the offer as online only, with shippinglimited to certain physical locations.

As mentioned above, database 277 also stores wallet client applicationinformation about a wallet client application (e.g., wallet clientapplication 125-1) on a mobile device (e.g., mobile device 120-1), andmay include associated wallet client application location data, such asthat in the Wallet Client Application Location Table (Table 2).

In that regard, Table 2 may store the internal ID of offers which matchthe current location of the wallet client application. An internal ID inthis context may be a number, letter, character string, or the like inthe wallet server which identifies the wallet client application (e.g.,wallet client application 125-1), or the corresponding mobile device(e.g., mobile device 120-1).

Location Data defines the location of the wallet client application andmobile device. As with the location data and range of the offer itself,the location of the wallet client application and/or mobile device maybe defined as a set of GPS coordinates, by using a zip code, by usingpolitical divisions such as cities, and the like.

The ID # from the Merchant Offers Table indicates an internal ID of anoffer which matches the location data of the wallet client applicationand/or mobile device. As discussed below, this matching may be performedby user agent 276 of wallet server system 170. Thus, for example, sincethe location data of the wallet client application with internal ID 88is within the location data and range defined by the offer with internalID 99, these items are correlated by user agent 276, and added to Table2 in database 277 as a match.

In more detail, communicated offer content received by the wallet serversystem 170 from merchant system 140-1 is stored within the wallet serverdatabase 277. Once an offer campaign is initiated, a user agent 276 ofthe wallet server system 170 compares wallet client application locationdata (e.g., the location data stored in Table 2 in database 277) withthe location and range defined by the offer (e.g., the Merchant DefinedLocation Data and Associated Range data stored in Table 1 in database277) to identify one or more wallet client applications on respectivemobile devices (e.g., the wallet client application 125-1 on mobiledevice 120-1) which fall within the location and range defined by theoffer. Thus, user agent 276 identifies a pool of eligible applicationsfrom the plurality of applications, based on the application locationinformation of each of the plurality of applications and at least one ofthe location data and range of one of the one or more sets of data(e.g., offers).

Once corresponding merchant offers and wallet client applications areidentified based on the comparison between the wallet client applicationlocation data and the location data and range of the offer, user agent276 of wallet server system 170 retrieves wallet client applicationinformation of the eligible application(s) and/or corresponding mobiledevice(s), such as network address, port information, response routinginformation and offer content.

A communications message may then be generated by user agent 276,including network and application routing information, offer content(e.g. from Table 1 in database 277), and presentation information suchas code or instructions for graphically displaying the offer on a mobiledevice, and sent to the wallet client application (e.g., wallet clientapplication 125-1).

For example, a wallet client application offer message 258 may include amessage body (offer body information 254), offer identificationinformation 255 that may include an inventory location identifier,response routing information 256 which mobile device 120-1 can use toroute a response back to the merchant system 140-1, and wallet clientrouting information 257 for routing the message to the wallet clientapplication 125-1. The offer message 258 may include, in offer bodyinformation 254 or elsewhere, the location and range defined by theoffer, store specific location data, and offer use capabilities and/orrestrictions.

As shown in FIG. 2 , mobile device 120-1 includes wallet clientapplication 125-1 for causing the mobile device to act as an instrument,for example, for processing contactless transactions, as well as forpresenting (e.g. displaying) offers or other sets of data received fromwallet server system 170, as described more fully below.

Mobile device 120-1 further includes a processor 221, a memory kerneland OS 222, and network interface 224. In that regard, the generalstructure and function of processor 221, memory OS and kernel 222, andnetwork interface 224 corresponds to the same elements described abovewith respect to merchant system 140-1, and as such for purposes ofconciseness will not be repeated. Of course, it should be understoodthat the specific functions of these elements may be tailored to thefunctionality of mobile device 120-1.

Location services interface 223 is hardware and/or software forobtaining, e.g., location data of the mobile device 120-1, such as by,e.g., communication with a GPS satellite or RF location methods.Moreover, location services interface 223 may periodically transmit suchinformation to wallet server system 170, so that wallet server system170 can use this information in matching mobile device 120-1 to offersor other sets of data received from merchant system 140-1.Alternatively, location services interface 223 may respond to periodicqueries from wallet server system 170 for such information.

User wallet client application interface 225 is hardware and/or softwarefor interfacing the other components of mobile device 120-1 with walletclient application 125-1. For example, wallet client application 125-1communicates with database 226 to obtain offer identificationinformation (offer ID information 251) to transmit to merchant system140-1 in the case that there is a selection of an offer on mobile device120-1.

Database 226 is hardware and/or software for storing an organizedcollection of data, such as received offers and offer contenttransmitted from wallet server system 170.

Host-based Card Emulation (HCE) interface 227 is hardware and/orsoftware for using the near field communications (NFC) interface onmobile device 120-1 to allow the mobile device 120-1 to act as acontactless card in order to, e.g. make a payment, present a ticket,show an ID card, and the like.

Mobile device 120-1 further includes near field communications (NFC)/SE228. The NFC includes hardware and/or software for short-range wirelesscommunication. The secure element (e.g., secure memory and executionenvironment) is a dynamic environment in which application code andapplication data can be securely stored and administered and in whichsecure execution of applications occurs. As described above with respectto FIG. 1 , the secure element may be implemented as a UICC, embedded SEcard, microSD card, and the like.

As can be seen in FIG. 2 , a wallet client application offer message istransmitted from wallet server system 170 to wallet client application125-1 on mobile device 120-1. As described above, a wallet clientapplication offer message 258 comprises a message body (offer bodyinformation 254), offer identification information 255 that may includean inventory location identifier, response routing information 256 forrouting a response to the merchant system 140-1, and wallet clientrouting information 257 for routing the message to the wallet clientapplication. The offer message 258 may include, in offer bodyinformation 254 or elsewhere, the location and range defined by theoffer, store specific location data, and offer use capabilities and/orrestrictions.

As offers are received by the wallet client application 125-1 at mobiledevice 120-1, they are stored (e.g., into database 226). In response toa user of mobile device 120-1 requesting access to a user interface foraccessing and viewing stored offers, offers are read from the database226 or memory 222, encoded with presentation logic (e.g., data forappropriately displaying the offer), and written to an instance variablefor display.

Offer message 258, and in particular offer body information 254, mayinclude a first link for enabling online purchasing of the merchantidentified product (including, e.g., the Merchant Offer ID from Table 1)and an optional second link for retrieving location information thatidentifies where use of the offer is valid for in-store use (e.g.,stores corresponding to the “Local Specific Store Data” in Table 1).

The first link (online purchasing) is used by wallet client applicationinterface 225 to obtain routing information 253. Routing information 253is used for routing the message over a secure transport channel toeither wallet server system 170 or the merchant server system 140-1. Forexample, routing information 253 identifies application resourcemanagement interfaces from a merchant system, wallet server system orboth (e.g., an Internet Protocol (IP) address of web page from which aproduct may be purchased). Routing information 253 may be pre-storedbased on, e.g., registering an account with the wallet server system170, merchant system 140-1, or both, or may be received with offercontent as response routing information 256. Wallet client applicationinterface 225 further obtains user personal account information 252,such as billing and contact information, and payment credentialinformation stored in memory, e.g., memory managed by the secureelement, and offer identification information 251 (e.g., the sameMerchant Offer ID identifying the offer at wallet server system 170 inTable 1).

A purchase request message 250 is generated by wallet client application125-1, and includes relevant information such as offer identificationinformation 251, account information 252, and routing information 253.

Once this information is received by the merchant system 140-1, thepayment transaction can be procured using payment and/or commercetransaction machinery of merchant system 140-1.

For example, once the merchant system 140-1 retrieves the purchaserequest message 250, merchant resource management tools may retrieve aninventory location identifier (not shown), to complete the shippingrequirements needed to complete the transaction. The inventory locationidentifier can be used by the merchant resource management tools todetermine location(s) of the merchant's supply chain inventory fromwhich the offered product can be shipped. Alternatively, the purchaserequest message 250 and offer identification information 251 can betransmitted to a specific merchant system application program interface(API) at merchant system 140-1, which determines from where the offeredproduct within the supply chain is to be shipped. Thus, in this example,the specified merchant system API defines a specific resource managementtool within the merchant inventory management system that, along withoffer identification information 251, can be used to determine fromwhere in the supply chain inventory is shipped.

As mentioned above, offer message 258 may also include a second link forretrieving location information that identifies where use of the offeris valid for in-store use (e.g., stores corresponding to the “LocalSpecific Store Data” in Table 1). The second link may be used by thewallet client application interface 225 to retrieve store locationinformation for display by wallet client application 125-1 via a displayof mobile device 120-1. The second link may be present when mobiledevice 120-1 is in a relevant location (e.g. a location within theMerchant Defined Location Data and Associated Range stored in Table 1),determined by a physical address, such as a zip code, or GPScoordinates. Thus, if the second link is selected, mobile device 120-1displays in-store options for using the offer and predefined locations.

Process

FIG. 3 is a flowchart illustrating the steps for providinglocation-based distribution of data according to an exemplaryembodiment.

In one example embodiment, one or more sets of data including a locationdata and a range are received from partner systems. In particular, inthis embodiment, the plurality of applications are wallet clientapplications on mobile devices (e.g., wallet client application 125-1 onmobile device 120-1), the partner systems are merchant systems (e.g.,merchant system 140-1) managed by corresponding merchants, and the oneor more sets of data include offer content. For example, the offercontent may include an offer of goods or services and may be redeemedwithin a predetermined period of time.

In more detail, in step 301, offer content is received and stored.Specifically, wallet server system 170 stores one or more sets of datareceived from one of a plurality of partner systems 140-1, each set ofdata including at least one of a location data and a range. For example,wallet server system 170 receives offer content generated by a merchantsystem 140-1, and stores it in database 277. As shown above in Table 1,the offer content may include, for example, an Internal ID, a MerchantOffer ID, a Merchant Defined Location Data and Associated Range, OfferContent (e.g., the actual offer or discount, such as “30% off laptopcomputers”), Local Specific Store Data, and a Use Case.

In step 302, wallet server system 170 retrieves information in itsdatabase 277 corresponding to the wallet client application devices orsystems managed by wallet server system 170, and in particularapplication information which includes, for example, applicationlocation information identifying the location of the correspondingmobile device. As mentioned above, mobile devices 120 may periodicallytransmit location data obtained by, e.g., communication with a GPSsatellite or RF location methods to wallet server system 170, or walletserver system 170 may query for such information. Thus, there isretrieval of application information associated with each application ofa plurality of applications stored on respective mobile devices, theapplication information including at least application locationinformation.

In step 303, wallet server system 170 identifies a pool of eligibleapplications from the plurality of applications, based on theapplication location information of each of the plurality ofapplications and at least one of the location data and range of one ofthe one or more sets of data in the received offer content. As describedabove with respect to FIG. 2 , the location data and range of each setof data (e.g., offer) can be defined by the respective merchant system140-1, the location data can be specific coordinates indicating wherethe set of data may be used (e.g., redeemed), and the range can bepredetermined area relative to the location (e.g., 20 miles). Theapplication location information includes location information about thecorresponding wallet client application 125, such as at least one of azip code in which wallet client application 125-1 and/or mobile device120-1 is located. Accordingly, it is possible to identify the eligibleapplication/mobile devices by, for example, determining whether theapplication location information falls within the range defined by themerchant system 140-1 in the set of data (e.g., in the offer).

In step 304, a message is generated for each of the applications in thepool of eligible applications, the message including at least a portionof the one of the one or more sets of data (e.g., the offer). Asdescribed above with respect to FIG. 2 , for example, an offer message258 may include at least a message body, a first link for enablingonline purchasing of the merchant identified product (including, e.g.,the Merchant Offer ID from Table 1) and an optional second link forretrieving location information that identifies where use of the offeris valid for in-store use (e.g., stores corresponding to the “LocalSpecific Store Data” in Table 1).

Thus, a merchant enabled offer can be pushed, in a batch process foreither a specific location area, regionally, or nationwide, to walletclient applications. The offer includes content that enables logic inthe wallet client application to display the offer with a selectablepayment item that indicates that payment is for online purchase only,and an optional and selectable item for retrieving a map and displayingon the map store locations where the merchandise can be purchasedin-store.

In step 305, the respective message(s) are transmitted, over acommunications network, to the applications in the pool of eligibleapplications. Thus, referring back to the example in FIG. 1 , the offermessage is transmitted from wallet server system 170 in MoCom platform130, across communication network 150, to mobile devices 120-1, 120-2 .. . . 120-n, as applicable.

The mobile device, e.g., mobile device 120-1, receives the message, and,in one example embodiment, displays a user interface based on themessage.

FIG. 4 is a view for illustrating location-based distributed datadisplayed on a mobile device according to an exemplary embodiment.

As shown in FIG. 4 , user interface 401 displays information about anoffer, such as the subject of the offer and the expiration date. Asshown in FIG. 4 , user interface 401 also displays selectable “In Store”object 402, and selectable “Online” object 403.

Selection of the “In Store” object 402 loads and/or displays anotheruser interface including, for example, a map of the location (e.g., astore) designated by the offer content. In some embodiments, this object402 may only be present when the mobile device is in a relevant locationdetermined by a physical address, such as zip code or coordinates fromGPS services or from the designated location.

Selection of the “Online” object 403 loads and/or displays another userinterface including information and/or options for purchasing online,and may link directly to a merchant's website. Thus, in one embodiment,the consumer UI feature (e.g., offer on a mobile device) may includeembedded link data through which the offer content would redirect theconsumer to the respective merchant's website which includes specificproduct information. In this embodiment, the purchase request message250 would include the routing information and the offer identificationinformation. The merchant then receives all the information necessary toprocure necessary inventory from the designated location area tofacilitate purchase.

In one example, the wallet client application logic, when triggered byactions of a user of the wallet client application to purchase theproduct online via object 403, automatically pulls up a shipping andbilling address form 405 and automatically populates this informationfrom pre-existing address information, if it exists, e.g. from a userprofile associated with the wallet client application. Additionally, aPrimary Account Number (PAN) identification data, e.g. a payment token,used to identify PAN data, or actual PAN data, may be retrieved fromsecure storage area, e.g. from a secure storage area of a Host CardEmulation (HCE) environment, SE storage environment, or a networkcentric secure storage area. The type of PAN data used and where it isstored may be implementation dependent, i.e. dependent for a particularwireless handset device and a particular service provider. For example,Softcard, Apple, and Google each have different methods of using walletclient payment credentials for online transactions.

In this embodiment, a request from the wallet client application 125-1through the wallet client application interface 225 to the facilitywhere PAN identification data is stored locally and/or securely, e.g. instorage area associated with NFC/SE 228 or HCE 227, requesting the databe made available to wallet client application 125-1. The PANidentification data may include the PAN, or an identifier of the PAN,the Card Verification Value (CVV), account holder name, expiration data,and any control data indicating the PAN data is for use for an onlinetransaction. The wallet client application 125-1 then can generate thepurchase request message 250 and have the message 250 routed to theappropriate destination. The ultimate destination being the merchantsystem where account information 252 is routed through a payment gatewayto an appropriate payment network for transferring funds and offeridentification information 251 can be used to have merchant inventorymoved from a particular location to the consumer.

It should be understood that the user interfaces and information shownin FIG. 4 are merely examples, and that various other types ofinterfaces and information could be displayed.

Example Computer-Readable Medium Implementations

The example embodiments described above such as, for example, thesystems and procedures depicted in or discussed in connection with FIGS.1-4 or any part or function thereof, may be implemented by usinghardware, software or a combination of the two. The implementation maybe in one or more computers or other processing systems. Whilemanipulations performed by these example embodiments may have beenreferred to in terms commonly associated with mental operationsperformed by a human operator, no human operator is needed to performany of the operations described herein. In other words, the operationsmay be completely implemented with machine operations. Useful machinesfor performing the operation of the example embodiments presented hereininclude general purpose digital computers or similar devices.

FIG. 5 is a block diagram of a general and/or special purpose computer500, which may be a general and/or special purpose computing device, inaccordance with some of the example embodiments of the invention. Thecomputer 500 may be, for example, a user device, a user computer, aclient computer and/or a server computer, among other things.

The computer 500 may include without limitation a processor device 530,a main memory 535, and an interconnect bus 537. The processor device 530may include without limitation a single microprocessor, or may include aplurality of microprocessors for configuring the computer 500 as amulti-processor system. The main memory 535 stores, among other things,instructions and/or data for execution by the processor device 530. Themain memory 535 may include banks of dynamic random access memory(DRAM), as well as cache memory.

The computer 500 may further include a mass storage device 540,peripheral device(s) 542, portable non-transitory storage mediumdevice(s) 546, input control device(s) 544, a graphics subsystem 548,and/or an output display 549. For explanatory purposes, all componentsin the computer 500 are shown in FIG. 5 as being coupled via the bus537. However, the computer 500 is not so limited. Devices of thecomputer 500 may be coupled via one or more data transport means. Forexample, the processor device 530 and/or the main memory 535 may becoupled via a local microprocessor bus. The mass storage device 540,peripheral device(s) 542, portable storage medium device(s) 546, and/orgraphics subsystem 548 may be coupled via one or more input/output (I/O)buses. The mass storage device 540 may be a nonvolatile storage devicefor storing data and/or instructions for use by the processor device530. The mass storage device 540 may be implemented, for example, with amagnetic disk drive or an optical disk drive. In a software embodiment,the mass storage device 540 is configured for loading contents of themass storage device 540 into the main memory 535.

The portable storage medium device 546 operates in conjunction with anonvolatile portable storage medium, such as, for example, a compactdisc read only memory (CD-ROM), to input and output data and code to andfrom the computer 500. In some embodiments, the software for storinginformation may be stored on a portable storage medium, and may beinputted into the computer 500 via the portable storage medium device546. The peripheral device(s) 542 may include any type of computersupport device, such as, for example, an input/output (I/O) interfaceconfigured to add additional functionality to the computer 500. Forexample, the peripheral device(s) 542 may include a network interfacecard for interfacing the computer 500 with a network 439.

The input control device(s) 544 provide a portion of the user interfacefor a user of the computer 500. The input control device(s) 544 mayinclude a keypad and/or a cursor control device. The keypad may beconfigured for inputting alphanumeric characters and/or other keyinformation. The cursor control device may include, for example, ahandheld controller or mouse, a trackball, a stylus, and/or cursordirection keys. In order to display textual and graphical information,the computer 500 may include the graphics subsystem 548 and the outputdisplay 549. The output display 549 may include a cathode ray tube (CRT)display and/or a liquid crystal display (LCD). The graphics subsystem548 receives textual and graphical information, and processes theinformation for output to the output display 549.

Each component of the computer 500 may represent a broad category of acomputer component of a general and/or special purpose computer.Components of the computer 500 are not limited to the specificimplementations provided here.

Software embodiments of the example embodiments presented herein may beprovided as a computer program product, or software, that may include anarticle of manufacture on a machine-accessible or machine-readablemedium having instructions. The instructions on the non-transitorymachine-accessible machine-readable or computer-readable medium may beused to program a computer system or other electronic device. Themachine- or computer-readable medium may include, but is not limited to,floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks orother types of media/machine-readable medium suitable for storing ortransmitting electronic instructions. The techniques described hereinare not limited to any particular software configuration. They may findapplicability in any computing or processing environment. The terms“computer-readable”, “machine-accessible medium” or “machine-readablemedium” used herein shall include any medium that is capable of storing,encoding, or transmitting a sequence of instructions for execution bythe machine and that causes the machine to perform any one of themethods described herein. Furthermore, it is common in the art to speakof software, in one form or another (e.g., program, procedure, process,application, module, unit, logic, and so on), as taking an action orcausing a result. Such expressions are merely a shorthand way of statingthat the execution of the software by a processing system causes theprocessor to perform an action to produce a result.

Portions of the example embodiments of the invention may be convenientlyimplemented by using a conventional general purpose computer, aspecialized digital computer and/or a microprocessor programmedaccording to the teachings of the present disclosure, as is apparent tothose skilled in the computer art. Appropriate software coding mayreadily be prepared by skilled programmers based on the teachings of thepresent disclosure.

Some embodiments may also be implemented by the preparation ofapplication-specific integrated circuits, field programmable gatearrays, or by interconnecting an appropriate network of conventionalcomponent circuits.

Some embodiments include a computer program product. The computerprogram product may be a storage medium or media having instructionsstored thereon or therein which can be used to control, or cause, acomputer to perform any of the procedures of the example embodiments ofthe invention. The storage medium may include without limitation afloppy disk, a mini disk, an optical disc, a Blu-ray Disc, a DVD, a CDor CD-ROM, a micro-drive, a magneto-optical disk, a ROM, a RAM, anEPROM, an EEPROM, a DRAM, a VRAM, a flash memory, a flash card, amagnetic card, an optical card, nanosystems, a molecular memoryintegrated circuit, a RAID, remote data storage/archive/warehousing,and/or any other type of device suitable for storing instructions and/ordata.

Stored on any one of the computer readable medium or media, someimplementations include software for controlling both the hardware ofthe general and/or special computer or microprocessor, and for enablingthe computer or microprocessor to interact with a human user or othermechanism utilizing the results of the example embodiments of theinvention. Such software may include without limitation device drivers,operating systems, and user applications. Ultimately, such computerreadable media further include software for performing example aspectsof the invention, as described above.

Included in the programming and/or software of the general and/orspecial purpose computer or microprocessor are software modules forimplementing the procedures described above.

While various example embodiments of the present invention have beendescribed above, it should be understood that they have been presentedby way of example, and not limitation. It will be apparent to personsskilled in the relevant art(s) that various changes in form and detailcan be made therein. Thus, the present invention should not be limitedby any of the above-described example embodiments, but should be definedonly in accordance with the following claims and their equivalents.

In addition, it should be understood that the accompanying figures arepresented for example purposes only. The architecture of the exampleembodiments presented herein is sufficiently flexible and configurable,such that it may be utilized and navigated in ways other than that shownin the accompanying figures. Further, the purpose of the foregoingAbstract is to enable the U.S. Patent and Trademark Office and thepublic generally, and especially the scientists, engineers andpractitioners in the art who are not familiar with patent or legal termsor phraseology, to determine quickly from a cursory inspection thenature and essence of the technical disclosure of the application. TheAbstract is not intended to be limiting as to the scope of the exampleembodiments presented herein in any way. It is also to be understoodthat the procedures recited in the claims need not be performed in theorder presented.

1-20. (canceled)
 21. A system to automatically provide location-baseddistribution of online and in-store offers, comprising: at least onememory operable to store one or more offers received from a merchantsystem, each offer including an offer location, an associated offerrange, and one or more merchant applications associated with the one ormore offers; an interface to communicate with the merchant system; and aprocessor communicatively coupled to the memory and the interface, theprocessor being operable to perform operations comprising: receivinglocation data from a user mobile computing device, the location datadescribing a location of the user mobile computing device; automaticallygenerating an offer message, the offer message including at least onerespective offer from the one or more offers; adding a first link to theoffer message, the first link enabling a user to conduct a remotetransaction based on the at least one respective offer; determining thatthe user mobile computing device is within an offer range associatedwith the at least one respective offer; in response to determining thatthe at least one respective offer is located within the associated offerrange generate a map for the at least one respective offer: generating amap for the at least one respective offer; adding a second link to themessage, wherein the second link includes a selectable item thatretrieves the map displaying the offer location of the one or moreeligible offers; and transmit, over a communications network,instructions to cause the user mobile computing device to display themessage.
 22. The system of claim 21, the operations further comprising:identifying one or more applications on a user mobile computing device;and determining that the one or more applications on the user mobilecomputing device match the one or more merchant application.
 23. Thesystem of claim 22, wherein the one or more applications are mobilewallet client applications.
 24. The system of claim 21, whereindetermining that the user mobile computing device is within an offerrange associated with the at least one respective offer furthercomprises: determining a location associated with the at least onerespective offer.
 25. The system of claim 24, wherein determining thatthe user mobile computing device is within an offer range associatedwith the at least one respective offer further comprises: determining adistance between the user mobile computing device and the locationassociated with the at least one respective offer; and determining thatthe distance between the user mobile computing device and the locationassociated with the at least one respective offer is less than apredetermined offer range.
 26. The system of claim 21, wherein the offerlocation and the associated offer range are defined by the merchantsystem, the offer location being coordinates indicating where arespective offer may be redeemed, and the associated offer range being apredetermined area relative to the offer location.
 27. The system ofclaim 21, wherein the one or more offers include an offer of goods orservices and may be redeemed within a predetermined period of time. 28.The system of claim 21, wherein the data includes at least one of a zipcode in which the user mobile computing device is located.
 29. A methodto automatically provide location-based distribution of online andin-store offers, comprising: by one or more computing devices: receivinglocation data from a user mobile computing device, the location datadescribing a location of the user mobile computing device; automaticallygenerating an offer message, the offer message including at least onerespective offer from the one or more offers; adding a first link to theoffer message, the first link enabling a user to conduct a remotetransaction based on the at least one respective offer; determining thatthe user mobile computing device is within an offer range associatedwith the at least one respective offer; in response to determining thatthe at least one respective offer is located within the associated offerrange generate a map for the at least one respective offer: generating amap for the at least one respective offer; adding a second link to themessage, wherein the second link includes a selectable item thatretrieves the map displaying the offer location of the one or moreeligible offers; and transmit, over a communications network,instructions to cause the user mobile computing device to display themessage.
 30. The method of claim 29, further comprising identifying oneor more applications on a user mobile computing device; and determiningthat the one or more applications on the user mobile computing devicematch the one or more merchant application.
 31. The method of claim 30,wherein the one or more applications are mobile wallet clientapplications.
 32. The method of claim 29, wherein determining that theuser mobile computing device is within an offer range associated withthe at least one respective offer further comprises: determining alocation associated with the at least one respective offer.
 33. Themethod of claim 32, wherein determining that the user mobile computingdevice is within an offer range associated with the at least onerespective offer further comprises: determining a distance between theuser mobile computing device and the location associated with the atleast one respective offer; and determining that the distance betweenthe user mobile computing device and the location associated with the atleast one respective offer is less than a predetermined offer range. 34.The method of claim 29, wherein the offer location and the associatedoffer range are defined by the merchant system, the offer location beingcoordinates indicating where a respective offer may be redeemed, and theassociated offer range being a predetermined area relative to the offerlocation.
 35. The method of claim 29, wherein the one or more offersinclude an offer of goods or services and may be redeemed within apredetermined period of time.
 36. The method of claim 29, wherein thedata includes at least one of a zip code in which the user mobilecomputing device is located.
 37. A non-transitory computer-readablemedium storing instructions that, when executed by one or more computingdevices, cause the one or more computing devices to perform operations,the operations comprising: receiving location data from a user mobilecomputing device, the location data describing a location of the usermobile computing device; automatically generating an offer message, theoffer message including at least one respective offer from the one ormore offers; adding a first link to the offer message, the first linkenabling a user to conduct a remote transaction based on the at leastone respective offer; determining that the user mobile computing deviceis within an offer range associated with the at least one respectiveoffer; in response to determining that the at least one respective offeris located within the associated offer range generate a map for the atleast one respective offer: generating a map for the at least onerespective offer; adding a second link to the message, wherein thesecond link includes a selectable item that retrieves the map displayingthe offer location of the one or more eligible offers; and transmit,over a communications network, instructions to cause the user mobilecomputing device to display the message.
 38. The non-transitorycomputer-readable medium of claim 37, further comprising: identifyingone or more applications on a user mobile computing device; anddetermining that the one or more applications on the user mobilecomputing device match the one or more merchant application.
 39. Thenon-transitory computer-readable medium of claim 37, wherein determiningthat the user mobile computing device is within an offer rangeassociated with the at least one respective offer further comprises:determining a location associated with the at least one respectiveoffer.
 40. The system of claim 39, wherein determining that the usermobile computing device is within an offer range associated with the atleast one respective offer further comprises: determining a distancebetween the user mobile computing device and the location associatedwith the at least one respective offer; and determining that thedistance between the user mobile computing device and the locationassociated with the at least one respective offer is less than apredetermined offer range.